3D Sports Playbook

ABSTRACT

This document generally describes techniques, methods, systems, and computer program products for providing a three-dimensional (“3D”) sports playbook. Such a playbook may permit someone like a football, basketball, or soccer coach to see a play executed in a classic X&#39;s and O&#39;s overhead two-dimensional (“2D”) view, and also in a 3D view.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. §119(e) of U.S.Patent Application No. 61/446,948, filed Feb. 25, 2011, which isincorporated herein by reference in its entirety.

TECHNICAL FIELD

This document generally describes techniques, methods, systems, andcomputer program products for providing a 3D sports playbook.

BACKGROUND

Coaches of various sports, like football, have used playbooks to designand implement plays for their teams. For example, a playbook for afootball team can include various football plays, such as offensiveplays (e.g., running plays, passing plays) and defensive plays (e.g.,blitz plays, pass defense plays). A play includes a coordinated sequenceof actions by some or all members of a team. Plays can be depicted in aplaybook with icons (e.g., X's and O's) representing players and withother marks indicating various actions taken by each player. Forexample, a football play can depict routes that are run by players aslines extending from a starting position to an end position for eachplayer as part of the play.

SUMMARY

This document generally describes techniques, methods, systems, andcomputer program products for providing a three-dimensional (“3D”)sports playbook. Such a playbook may permit someone like a football,basketball, or soccer coach to see a play executed in a classic X's andO's overhead two-dimensional (“2D”) view, and also in a 3D view. Ineither view, the players can be rendered as life-like players, or asicons that are representative of players but that do not resemble actualplayers. In addition, the coach can see the play as if viewing the playfrom the perspective of one of the players. For example, a footballcoach can have the play played out, where a camera view can represent aview that a pulling guard sees as the play is run (according to itsplanned execution), so as to obtain an appreciation for what the guardwill see.

In certain implementations, the execution by each player can be set sothat the play runs the same each time. In other examples, the executionof each player may vary—e.g., players can do a better or worse job—sothat a coach can see variability that may occur when the play isactually executed. A coach may also apply ability levels to each of thesimulated players so as to affect how well and how consistently theyexecute the play. For example, a large and talented lineman in footballmay be made to push his opponent farther backward than would a smaller,less able lineman. Likewise, test information for each player may beinput so that, for example, the smaller lineman will reach the cornerfaster when pulling will than a larger, slower lineman.

In one implementation, a computer-implemented method includes receiving,at a computing device, user input to display a sports play that involvesa plurality of players; displaying, by the computing device, the play inboth a 2D interface and a 3D interface using data associated with theplay and the plurality of players; in response to an indication for the3D interface to use a camera view that follows a particular player fromamong the plurality of players, adjusting the camera view of the 3Dinterface based on a location of the particular player in the play; andin response to an indication to run the play, displaying the pluralityof players moving synchronously in the 2D interface and in the 3Dinterface in a manner determined before the play is run and according toroutes associated with the players, wherein the 3D interface displaysthe synchronous motion of the players from the camera view based on thelocation of the particular player and a route associated with theparticular player.

In another implementation, a computer program product tangibly embodiesin a non-transitory computer readable medium including instructionsthat, when executed, cause a computing device with a processor toperform operations including receiving, at a computing device, userinput to display a sports play that involves a plurality of players;displaying, by the computing device, the play in both a 2D interface anda 3D interface using data associated with the play and the plurality ofplayers; in response to an indication for the 3D interface to use acamera view that follows a particular player from among the plurality ofplayers, adjusting the camera view of the 3D interface based on alocation of the particular player in the play; and in response to anindication to run the play, displaying the plurality of players movingsynchronously in the 2D interface and in the 3D interface in a mannerdetermined before the play is run and according to routes associatedwith the players, wherein the 3D interface displays the synchronousmotion of the players from the camera view based on the location of theparticular player and a route associated with the particular player.

In another implementation, a computer system includes a computing devicethat includes at least one processor; an input device of the computingdevice to receive user input to display a sports play that involves aplurality of players; a display of the computing device to display theplay in both a 2D interface and a 3D interface using data associatedwith the play and the plurality of players; and a 3D playbookapplication of the computing device to: i) adjust a camera view of the3D interface based on a location of a particular player in the play inresponse receiving an indication for the 3D interface to follow theparticular player from among the plurality of players, and ii) cause thedisplay to present the plurality of players moving synchronously in the2D interface and in the 3D interface in a manner determined before theplay is run and according to routes associated with the players, whereinthe 3D interface displays the synchronous motion of the players from thecamera view based on the location of the particular player and a routeassociated with the particular player.

The details of one or more embodiments are set forth in the accompanyingdrawings and the description below. Various advantages can be providedby the disclosed techniques, systems, computer program products, andmethods. For example, a helpful tool for both coaches and players can beprovided. For instance, coaches can receive an accurate representationin 3D space of how a play will progress, specifically with regard tovantage point of various players running the play. Players can morereadily visualize their own actions for a play as well as the actions ofthe other players on the field.

Other features, objects, and advantages of the invention will beapparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIGS. 1-11 are screenshots of an example application that provides a 3Dplaybook.

FIG. 12 depicts an example computer system for providing a 3D playbook.

FIG. 13 is a flowchart of an example technique for displaying a playsynchronously in a 2D interface and a 3D interface.

FIG. 14 is a block diagram of computing devices that may be used toimplement the systems and methods described in this document, as eithera client or as a server or plurality of servers.

FIG. 15 is a flowchart of an example technique for changing a playthrough a 2D interface and synchronously displaying the changed play ina 3D interface.

FIG. 16 is a flowchart of an example technique for changing a playthrough a 3D interface and synchronously displaying the changed play ina 2D interface.

FIG. 17 is a flowchart of an example technique for adjusting theanimation of plays to account for route attributes, player attributes,and/or variability.

FIG. 18 is a flowchart of an example technique for generating videosfrom a playbook for particular players and/or positions.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

This document generally describes techniques, methods, systems, andcomputer program products providing a 3D sports playbook. In particular,the 3D playbook can present and animate a 2D play in 3D space accordingto the players and actions outlined in the 2D play. A user can viewplays in 3D space from one or more camera views, whether a stationaryview (e.g., from a point above and behind the play) or moving view(e.g., from the simulated viewpoint of one of the players in the play).A camera view of a play is a depiction of the play in 3D space from avantage point in the 3D space, generally not from directly above theplay. A 2D play is a view from above, generally with the playersrepresented by flat icons, such as an X for each offensive player and anO for each defensive player. Camera views can be adjusted manuallyand/or automatically. For example, a user can adjust a camera view byzooming in and out (e.g., using a scroll wheel on a mouse), and also bymoving the vantage point or viewing angle from which the camera view isprovided (e.g., moving a mouse). In another example, a camera view canbe set to automatically follow one or more players while a play is run(animated) in 3D space. A variety of following camera views can beprovided, such as a point of view for the player being followed (e.g., ahelmet camera view) and/or a camera view from behind the player thatfocuses on the player.

Changes to a play made in 2D space can be dynamically and automaticallyreflected in a 3D rendering and/or animation of a play. For instance, 2Dand 3D depictions of a play can be based on common data (e.g., playerdata, route data), so that a change in the data, such as moving aplayer's position and/or route, is automatically reflected in both 2Dand 3D depictions on the fly. For example, in a football play, if a widereceiver is moved from the left side of the field to the right side ofthe field in a 2D depiction of a play, this change in positioning can beautomatically reflected in the 3D rendering of the play. In anotherexample, if a running back's route is changed in the 2D depiction of aplay, the change in the players route can automatically be reflected inthe 3D rendering and animation of the play.

Changes to a play made in 3D space can also be dynamically andautomatically reflected in a 2D depiction of the play. For example, if auser selects a player in 3D space and moves the player to a differentlocation, the relocation of this player can be reflected in the 2Ddepiction of the play. Changes made to plays in 2D and/or 3D space canbe saved and retrieved for later viewing/editing.

FIG. 1 is a screenshot 100 of an example application that provides a 3Dplaybook. The example screenshot 100 presents an example footballplaybook. The screenshot 100 includes a 2D interface 102 that depicts a2D depiction of a play. The screenshot 100 also includes a 3D interface104 that provides a 3D rendering of the play. The 3D rendering of theplay in the 3D interface 104 corresponds to the 2D depiction of the playin the 2D interface 102. For example, the 2D interface 102 depicts aplayer 106 (a running back) and a route 108 that the player 106 is goingto run for the play. A corresponding 3D representation of the player 106is provided as player 110 in the 3D interface 104. Although not includedin the example screenshot 100, the route 108 can also be depicted in the3D interface 104.

The 2D and 3D interfaces 102 and 104 provide graphical elements thatcorrespond to players, routes, and the field with which a user caninteract through any of a variety of input devices (e.g., mouse,keyboard). For example, the player 106 is a graphical element that usercan select and drag to a different location in the 2D depiction of theplay. In another example, the route 108 is a graphical element a usercan edit and move to a different location in the 2D depiction of theplay. Such changes to the player 106 and/or the route 108 can bereflected in the 3D rendering of the play in the 3D interface 104. Forexample, if the player 106 is moved to a new location, then thecorresponding player 110 can be automatically moved to a correspondinglocation in the 3D interface 104. Similarly, the player 110 can be movedto a different location in the 3D interface 104, and the correspondingplayer 106 can be automatically moved to a corresponding location in the2D interface 102.

A field box 112 depicted in the 2D interface 104 is another graphicalelement with which users can interact. For example, the field box 112can be selected and dragged to the right so that the center lines up onthe left hash mark of the field. In response to such user interaction,the players can line up on the left hash mark in the 3D interface 104.The field box 112 can provide a convenient way for adjusting thelocation at which a play is taking play on the field.

Each of these graphical elements can correspond to one or more dataelements, such as a data object, and can have corresponding propertiesthat define various attributes of the elements. For example, players(e.g., player 106) can have a variety of corresponding properties, suchas properties regarding their name, speed (e.g., running speed), size(e.g., height), and/or appearance (e.g., an image of the player, a 3Dmodel of the player, a 3D motion-capture model of the player performingvarious actions). In another example, routes (e.g., route 108) can havea variety of corresponding properties, such as properties regardingtiming for the route (e.g., delay one second at the start of the playbefore running the route) and/or speed of the route (e.g., perform routeat half speed). In a further example, a field box (e.g., the field box112) can have a variety of properties, such as a location of the fieldbox relative to the field (e.g., field box located at 10 yard line).

When a graphical element is selected (e.g., has focus), propertiescorresponding to the graphical element can be presented in theproperties tab 114 of the application. In the example screenshot 100,the properties displayed in the properties tab 114 are propertiesassociated with the 3D interface 104. These properties include aproperty 116 for the type of camera view used in the 3D interface 104 torender a play. In the depicted example, the camera view is set to“free,” meaning that a user is able to dynamically toggle the cameraview in the 3D interface 104 through various inputs, such as moving apointer (e.g., moving a mouse). In the example screenshot 100, thecamera is positioned above and behind the offense in the 3D interface104. Other properties displayed in the properties tab 114 for the 3Dinterface 104 include adjustable uniform colors 118 for the teamsdepicted on the field.

Animation of the play in the 3D interface 104 and in the 2D interface102 can be controlled using buttons 120. The buttons 120 include arecord button, a rewind button, and a play button. The record button canbe used to record actions for a play, such as routes for various playersto run as part of a play. The rewind button can rewind playback to thebeginning of the play. And the play button can cause the play to be runaccording to the actions (e.g., routes) depicted in the 2D interface 102for the play (although not depicted in the screenshot 100, actions canalso be depicted in the 3D interface 104). Animation of a play can causeplayers to move according to the designated actions (e.g., routes) inboth the 2D interface 102 and the 3D interface 104. For instance, theblack circle for the player 106 in the 2D interface 102 and the 3Drepresentation of the player 110 in the 3D interface 104 can move insync according to the route 108 when the play is run (after the playbutton is pressed).

The example screenshot 100 also depicts a table of contents pane 122that provides an organized and expandable display of plays, formations,and print layouts. In the depicted example, the table of contents pane122 displays a library of formations for defense and offense. Formationscan serve as templates from which plays can be constructed. For example,instead of having to place individual players for each play that will beconstructed, previously created formations can be used as a startingpoint for play creation. Like plays, formations can be created anddisplayed in both the 2D interface 102 and 3D interface 104.

FIG. 2 is a screenshot 200 of an example application that provides a 3Dplaybook. The example screenshot 200 depicts the same 2D interface 102and the same 3D interface 104 as in the screenshot 100, but the table ofcontents pane 122 depicts an example of a user designed playbook. Eachof the plays listed in the playbook can be loaded into the 2D and 3Dinterfaces 102 and 104 for editing and playback. For example, selectionof the play “Sample_High_School” (highlighted in blue) can cause theplay to be loaded into the interfaces 102-104. Each of the plays cancorrespond to one or more data files that can be stored on a file systemand loaded for use by the application.

The plays can be organized in the pane 122 using the expandable folders.For example, a user can designate various categories of plays usingfolders and can organize plays by placing plays in correspondingfolders. For instance, the folder “Running Wild” includes two plays,“WishBone-1” and “WishBone-2.”

FIG. 3 is a screenshot 300 of an example application that provides a 3Dplaybook. The screenshot 300 depicts the 2D and 3D interfaces 102 and104, respectively. In the screenshot 300, the black circle representingplayer 106 has been selected by a user (e.g., mouse click on thecircle), as indicated by the square surrounding the circle. Selection ofthe player 106 causes the properties tab 114 to change to representproperties associated with the 2D representation of the player 106, suchas a name associated with the player 106 (“FB”) and a symbolcorresponding to the player (a black circle). Also, property 302indicates whether a 3D camera is set to follow the selected player inthe 3D interface 104. In the present example, the value for the property302 is set to true, which can cause the 3D interface 304 to change thecamera view from a free view (where the user controls the position ofthe camera), to a camera view that is automatically adjusted to followthe player 106. The information box 304 provides a description ofproperties in the properties tab 114 and, in this example, explains the3D follow property 302.

FIG. 4 is a screenshot 400 of an example application that provides a 3Dplaybook. The screenshot 400 depicts the 2D and 3D interfaces 102 and104, respectively. In the screenshot 400, the properties tab 114 hasbeen changed to the properties for the 3D interface 104. The property“follow location” 402 provides a few options for the camera positionwhen the camera is set to follow a particular player in the 3D interface104, such as the 3D player 110 which corresponds to the 2D player 106(which is depicted in FIG. 3 as having the 3D follow property 302 set totrue). In this example, locations for a follow camera include “behindthe player” (above and behind the player—providing a contextual view ofthe player's forward motion) and “player helmet” (a point of viewcamera). Other locations for a follow camera view are also possible,such as a bird's eye view (elevated view) that follows the player 110.Information box 404 provides an explanation of the follow locationproperty.

FIG. 5 is a screenshot 500 of an example application that provides a 3Dplaybook. The screenshot 500 depicts the 2D and 3D interfaces 102 and104, respectively. In the screenshot 500, the property 116 for thecamera type has been changed to “follow” and the follow locationproperty 402 has been changed to “behind player.” With the 3D “follow”property having been set to “true” for the 2D player 106 (3D player110), as described above with regard to FIG. 3, the camera view changesto a view from behind the player 110 in the 3D rendering of the play.

FIG. 6 is a screenshot 600 of an example application that provides a 3Dplaybook. The screenshot 600 depicts the 2D and 3D interfaces 102 and104, respectively. In the screenshot 600, the play depicted in theinterfaces 102 and 104 is midway through being run, as indicated by theanimation progress 602. The 2D and 3D interface 102 and 104 depict theanimation of the player 106/110 along the route 108. The 2D interface102 presents the player 106 as having progressed about halfway throughthe route 108. The icon representing the player 106 can move along theroute 108 as part of the play animation. Additionally, the 2D iconsrepresenting the other players on the field move according to theirrespective routes (and properties, like time delays) in the 2D interfacewhen the play is run/animated. The square box around the icon 106 canindicate that the camera view in the 3D interface 104 is focused on theplayer 106.

Concurrently and synchronously with movement of the player 106 in 2Dspace, the corresponding 3D player 110 moves along the route 108 in 3Dspace (along with the movement of the other players along theirrespective routes). Using a camera view that automatically followsbehind the player 110, the 3D interface 104 depicts the player 110midway through running the route 108. In this example, the camera viewof the 3D interface 104 is attached to the player and follows the playerwithout further action from the user. This feature can provide a helpfultool for both coaches and players. For instance, coaches can receive anaccurate representation in 3D space of how a play will progress,specifically with regard to vantage point of various players running theplay. Players can more readily visualize their own actions for a play aswell as the actions of the other players on the field.

A user can drag the animation progress indicator 602 to toggle the playforward or backward. When the progress indicator 602 is dragged, theplayers move to corresponding locations along their respective routes inthe 2D and 3D interface 102 and 104.

FIG. 7 is a screenshot 700 of an example application that provides a 3Dplaybook. The screenshot 700 depicts the 2D and 3D interfaces 102 and104, respectively. In the screenshot 700, the property 402 identifyingthe follow location of the camera is changed to “player helmet.”Accordingly, the camera in the 3D interface 104 changes to a view fromthe perspective of the player 106 (helmet view for player 106) along theroute 108 midway through the play, as indicated by the progressindicator 602. The camera view for the 3D interface 104 can changedynamically and on the fly (without having to regenerate, process, orcompile video for the play).

FIG. 8 is a screenshot 800 of an example application that provides a 3Dplaybook. The screenshot 800 depicts the 2D and 3D interfaces 102 and104, respectively. In the screenshot 800, the player 106 and the route108 are moved further into the backfield in the 2D interface 102. Forexample, a user can select the player 106 and/or the route 108, and dragthe selection to a desired location for the play. Edits to playerlocations and routes can be performed when the play is stopped and/orwhile the play is animated (being run) in the interfaces 102 and 104.The camera view (behind player 110) in the 3D interface 104 isautomatically adjusted on the fly to reflect the change in the locationof the player 106 and the route 108 at the current progress of the play,as indicated by the progress indicator 602. Similarly, the player 110and/or a route the player 110 is running (not depicted) can also beedited in the 3D interface 104, with the edits being automaticallyreflected in the 2D interface 102.

FIG. 9 is a screenshot 900 of an example application that provides a 3Dplaybook. The screenshot 900 depicts the 2D and 3D interfaces 102 and104, respectively. In the screenshot 900, the camera view is switchedfrom following the player 106/110 to instead being a free camera viewthat is not tethered to a player, as indicated by the property 116 beingset to “free.” In this example, the camera view in the 3D interface 104is set to an overhead view of midway through the play, as indicated bythe progress indicator 602. Such a change to the camera view and theproperty 116 can be made while the play is stopped and/or while the playis being run (animated). The screenshot 900 also depicts a few presetnon-tethered (free camera type) camera view options in the menu 902. Themenu 902 can be presented in response to a particular type of input inthe 3D interface 104, such as a right mouse click. The menu 902 includesa preset bird's eye view, a group of defense views, and a group ofoffense views. The offense views are expanded in the screenshot 902 toinclude preset cameras that are focused on the 50 yard line, the endzone, and the line of scrimmage. Selection of one of the options cancause the camera view for the 3D interface 104 to automatically changeto the desired view.

FIG. 10 is a screenshot 1000 of an example application that provides a3D playbook. The screenshot 1000 depicts the 2D and 3D interfaces 102and 104, respectively. An example formation is depicted in thescreenshot 1000. As described above, formations can serve as templatesfor plays and can be used to provide a starting place for playdevelopment. In the depicted example, the defensive formation 1002(“Nickle_4-2_Under_Cover_1”) is selected and depicted in the 2D and the3D interfaces 102 and 104, respectively. Formations can be designed andedited like plays. Formations can also be set as “read only,” so as toprotect from accidental edits. The camera view depicted in thescreenshot 1000 for the 3D interface 102 is an overhead view. Othercamera views of formations are also possible, like the camera viewsdescribed above with regard to camera views of plays.

FIG. 11 is a screenshot 1100 of an example application that provides a3D playbook. The screenshot 1100 depicts print layouts 1102 and 1104 fora play and a formation, respectively. The layouts 1102 and 1104 can beprovided to a printer for printing. A variety of differentplay/formation layouts 1106 are depicted, such as a layout with onelarge play at the top of a page and four smaller plays at the bottom ofthe page. Such layouts can be used to group related plays together. Playgrouping can be based on the organization of plays as described abovewith regard to FIG. 2.

FIG. 12 depicts an example computer system 1200 for providing a 3Dplaybook. The example system 1200 is depicted as including a computingdevice 1202 that provides a 3D playbook that is similar to the 3Dplaybooks described above with regard to FIGS. 1-11. The computingdevice 1202 can be any variety of computing devices, such as a desktopcomputer, a laptop computer, a computer server, a mobile device (e.g., asmartphone, a personal digital assistant (PDA), a cell phone), and/or atablet computing device.

The computing device 1202 includes a 3D playbook application 1204 thatis configured to present plays in a 2D and 3D interface, similar to theinterfaces 102 and 104 described above with regard to FIGS. 1-11. The 3Dplaybook application 1204, and its components, can be implemented inhardware (e.g., application specific integrated circuit (ASIC)) and/orsoftware (e.g., instructions that are executable by one or more computerprocessors). The 3D playbook application 1204 can include variouscomponents, such as a 3D graphics engine 1206 (e.g., OGRE 3D graphicsengine) and a 3D playbook application programming interface (API) 1208.The 3D graphics engine 1206 can render 3D graphics for a 3D interface ofthe 3D playbook application 1204, and the 3D playbook API 1208 caninclude various instructions and/or data for performing the featuresdescribed above with regard to FIGS. 1-11.

The computing device 1202 also includes an input device 1210 (e.g., amouse, a microphone, a touch-sensitive screen) and a display 1212 (e.g.,a computer monitor, a mobile device screen) that are configured toreceive user input for and to provide output from the 3D playbookapplication 1204.

The computing device 1202 can access data used for the 3D playbookapplication 1204 from a data repository 1214 (e.g., a database, a filesystem). The data repository 1214 can be local to and/or remote from thecomputer device 1202. The data repository 1214 can include a variety ofdata that may be used by the 3D playbook application 1204, such as dataregarding plays 1216, formations 1218, routes 1220, and/or players 1222.

The computing device 1202 can also include an input/output (I/O)interface 1224 (e.g., an Ethernet card, a wifi card) that is configuredto enable communication between the computing device 1202 and othercomputing devices over a network 1226. The network 1226 can be any of avariety of computer networks, such as a local area network (LAN), a widearea network (WAN), a wireless network, the Internet, a virtual privatenetwork (VPN), an optical network, or any combination thereof. Thecomputing device 1202 can communicate with various computing devices,such as computer server systems 1228 and 1230, over the network 1226 toprovide the 3D playbook application to a user of the computing device.For example, the 3D playbook application 1204 can be a web basedapplication that is hosted on the computer server system 1228 and thatis downloaded by the computing device 1202. In another example, some orall of the data in the data repository 1214 can be stored on and servedby the computer server system 1230 to the computing device 1202 over thenetwork 1226.

FIG. 13 is a flowchart of an example technique 1300 for displaying aplay synchronously in a 2D interface and a 3D interface. The technique1300 can be performed by any of a variety of computing devices, such asthe computing device 1202 described above with regard to FIG. 12. Thetechnique 1300 can be performed with and/or separately from the otherdescribed techniques.

The example technique 1300 starts at step 1302 by receiving input todisplay a play from a playbook. For example, input can be received inresponse to a user selecting a play from the list of plays provided inthe pane 122, as described above with regard to FIG. 2. The play anddata associated with the play (e.g., player data, route data) can beretrieved (step 1304). For example, the computing device 1202 canretrieve the play and other associated data from the data repository1214 described above with regard to FIG. 12. The play is displayed in a2D interface and a 3D interface using the retrieved data (step 1306).For example, a play is displayed in the 2D interface 102 and the 3Dinterface 104, as described above with regard to FIGS. 1-10.

An indication can be received for the 3D interface to follow aparticular player that is part of the displayed play (step 1308). Forexample, FIG. 3 depicts a user selecting the player 106 in the 2Dinterface 102 and setting the property 302 for the camera view in the 3Dinterface 104 to follow the corresponding 3D player 110. The camera viewin the 3D interface can be adjusted based on a location of theparticular player in the play (step 1310). For example, FIG. 5 depictsthe camera view for the 3D interface 104 being adjusted to be behind theplayer 110, and FIG. 7 depicts the camera view for the 3D interface 104being adjusted to be a point of view (helmet cam) for the player 110.

An indication is received to run the play (step 1312). For example, auser can select a play button for the play, as described above withregard to FIG. 1. In response to receiving the indication to run theplay, the players can be displayed as moving synchronously across the 2Dand 3D interfaces according to respective routes for the players (step1314). The display in the 3D interface can be based on the location ofthe particular player and a route associated with the particular player(step 1316). For example, FIGS. 5-6 depict the camera view in the 3Dinterface following the player 110 while the players in the 2D interfaceand the 3D interface move in synch. The technique can end after step1316.

Sports other than football can be provided in 3D playbooks, such assoccer, ice hockey, lacrosse, basketball, baseball, softball,volleyball, water polo, and/or rugby.

Video files can be generated and exported based on animation presentedin a 2D interface and/or a 3D interface. Video compilations can begenerated for particular players and/or for particular positions. Forexample, a collection of video files (or a single video file) for arunning back position can be generated from a playbook so that there isa video for each play that involves the running back position. Suchplayer/position specific video files can be generated using a cameraview that is attached to the player/position (e.g., point of viewcamera, behind player camera view). Similarly, separate video filesand/or collections of video files for each player on a team can beproduced for an individual play and/or for all of the plays within aplaybook.

A 3D playbook can also support multiple 3D interfaces. For example,multiple separate camera view can be displayed simultaneously indifferent 3D interfaces. For example, three 3D interfaces can be used todisplay a play as it progresses at a bird's eye view, a first point ofview camera angle from a first player's view, and a second point of viewcamera from a second player's view. In another example, a separate 3Dinterface can be provided to simultaneously display the point of viewfor each player of a team as they progress through a play. The separate3D interfaces can be labeled to indicate what is being shown in eachinterface.

FIG. 14 is a block diagram of computing devices 1400, 1450 that may beused to implement the systems and methods described in this document, aseither a client or as a server or plurality of servers. Computing device1400 is intended to represent various forms of digital computers, suchas laptops, desktops, workstations, personal digital assistants,servers, blade servers, mainframes, and other appropriate computers.Computing device 1450 is intended to represent various forms of mobiledevices, such as personal digital assistants, cellular telephones,smartphones, and other similar computing devices. Additionally computingdevice 1400 or 1450 can include Universal Serial Bus (USB) flash drives.The USB flash drives may store operating systems and other applications.The USB flash drives can include input/output components, such as awireless transmitter or USB connector that may be inserted into a USBport of another computing device. The components shown here, theirconnections and relationships, and their functions, are meant to beexemplary only, and are not meant to limit implementations describedand/or claimed in this document.

Computing device 1400 includes a processor 1402, memory 1404, a storagedevice 1406, a high-speed interface 1408 connecting to memory 1404 andhigh-speed expansion ports 1410, and a low speed interface 1412connecting to low speed bus 1414 and storage device 1406. Each of thecomponents 1402, 1404, 1406, 1408, 1410, and 1412, are interconnectedusing various busses, and may be mounted on a common motherboard or inother manners as appropriate. The processor 1402 can processinstructions for execution within the computing device 1400, includinginstructions stored in the memory 1404 or on the storage device 1406 todisplay graphical information for a GUI on an external input/outputdevice, such as display 1416 coupled to high speed interface 1408. Inother implementations, multiple processors and/or multiple buses may beused, as appropriate, along with multiple memories and types of memory.Also, multiple computing devices 1400 may be connected, with each deviceproviding portions of the necessary operations (e.g., as a server bank,a group of blade servers, or a multi-processor system).

The memory 1404 stores information within the computing device 1400. Inone implementation, the memory 1404 is a volatile memory unit or units.In another implementation, the memory 1404 is a non-volatile memory unitor units. The memory 1404 may also be another form of computer-readablemedium, such as a magnetic or optical disk.

The storage device 1406 is capable of providing mass storage for thecomputing device 1400. In one implementation, the storage device 1406may be or contain a computer-readable medium, such as a floppy diskdevice, a hard disk device, an optical disk device, or a tape device, aflash memory or other similar solid state memory device, or an array ofdevices, including devices in a storage area network or otherconfigurations. A computer program product can be tangibly embodied inan information carrier. The computer program product may also containinstructions that, when executed, perform one or more methods, such asthose described above. The information carrier is a computer- ormachine-readable medium, such as the memory 1404, the storage device1406, or memory on processor 1402.

The high speed controller 1408 manages bandwidth-intensive operationsfor the computing device 1400, while the low speed controller 1412manages lower bandwidth-intensive operations. Such allocation offunctions is exemplary only. In one implementation, the high-speedcontroller 1408 is coupled to memory 1404, display 1416 (e.g., through agraphics processor or accelerator), and to high-speed expansion ports1410, which may accept various expansion cards (not shown). In theimplementation, low-speed controller 1412 is coupled to storage device1406 and low-speed expansion port 1414. The low-speed expansion port,which may include various communication ports (e.g., USB, Bluetooth,Ethernet, wireless Ethernet) may be coupled to one or more input/outputdevices, such as a keyboard, a pointing device, a scanner, or anetworking device such as a switch or router, e.g., through a networkadapter.

The computing device 1400 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as astandard server 1420, or multiple times in a group of such servers. Itmay also be implemented as part of a rack server system 1424. Inaddition, it may be implemented in a personal computer such as a laptopcomputer 1422. Alternatively, components from computing device 1400 maybe combined with other components in a mobile device (not shown), suchas device 1450. Each of such devices may contain one or more ofcomputing device 1400, 1450, and an entire system may be made up ofmultiple computing devices 1400, 1450 communicating with each other.

Computing device 1450 includes a processor 1452, memory 1464, aninput/output device such as a display 1454, a communication interface1466, and a transceiver 1468, among other components. The device 1450may also be provided with a storage device, such as a microdrive orother device, to provide additional storage. Each of the components1450, 1452, 1464, 1454, 1466, and 1468, are interconnected using variousbuses, and several of the components may be mounted on a commonmotherboard or in other manners as appropriate.

The processor 1452 can execute instructions within the computing device1450, including instructions stored in the memory 1464. The processormay be implemented as a chipset of chips that include separate andmultiple analog and digital processors. Additionally, the processor maybe implemented using any of a number of architectures. For example, theprocessor 410 may be a CISC (Complex Instruction Set Computers)processor, a RISC (Reduced Instruction Set Computer) processor, or aMISC (Minimal Instruction Set Computer) processor. The processor mayprovide, for example, for coordination of the other components of thedevice 1450, such as control of user interfaces, applications run bydevice 1450, and wireless communication by device 1450.

Processor 1452 may communicate with a user through control interface1458 and display interface 1456 coupled to a display 1454. The display1454 may be, for example, a TFT (Thin-Film-Transistor Liquid CrystalDisplay) display or an OLED (Organic Light Emitting Diode) display, orother appropriate display technology. The display interface 1456 maycomprise appropriate circuitry for driving the display 1454 to presentgraphical and other information to a user. The control interface 1458may receive commands from a user and convert them for submission to theprocessor 1452. In addition, an external interface 1462 may be providein communication with processor 1452, so as to enable near areacommunication of device 1450 with other devices. External interface 1462may provide, for example, for wired communication in someimplementations, or for wireless communication in other implementations,and multiple interfaces may also be used.

The memory 1464 stores information within the computing device 1450. Thememory 1464 can be implemented as one or more of a computer-readablemedium or media, a volatile memory unit or units, or a non-volatilememory unit or units. Expansion memory 1474 may also be provided andconnected to device 1450 through expansion interface 1472, which mayinclude, for example, a SIMM (Single In Line Memory Module) cardinterface. Such expansion memory 1474 may provide extra storage spacefor device 1450, or may also store applications or other information fordevice 1450. Specifically, expansion memory 1474 may includeinstructions to carry out or supplement the processes described above,and may include secure information also. Thus, for example, expansionmemory 1474 may be provide as a security module for device 1450, and maybe programmed with instructions that permit secure use of device 1450.In addition, secure applications may be provided via the SIMM cards,along with additional information, such as placing identifyinginformation on the SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory,as discussed below. In one implementation, a computer program product istangibly embodied in an information carrier. The computer programproduct contains instructions that, when executed, perform one or moremethods, such as those described above. The information carrier is acomputer- or machine-readable medium, such as the memory 1464, expansionmemory 1474, or memory on processor 1452 that may be received, forexample, over transceiver 1468 or external interface 1462.

Device 1450 may communicate wirelessly through communication interface1466, which may include digital signal processing circuitry wherenecessary. Communication interface 1466 may provide for communicationsunder various modes or protocols, such as GSM voice calls, SMS, EMS, orMMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others.Such communication may occur, for example, through radio-frequencytransceiver 1468. In addition, short-range communication may occur, suchas using a Bluetooth, WiFi, or other such transceiver (not shown). Inaddition, GPS (Global Positioning System) receiver module 1470 mayprovide additional navigation- and location-related wireless data todevice 1450, which may be used as appropriate by applications running ondevice 1450.

Device 1450 may also communicate audibly using audio codec 1460, whichmay receive spoken information from a user and convert it to usabledigital information. Audio codec 1460 may likewise generate audiblesound for a user, such as through a speaker, e.g., in a handset ofdevice 1450. Such sound may include sound from voice telephone calls,may include recorded sound (e.g., voice messages, music files, etc.) andmay also include sound generated by applications operating on device1450.

The computing device 1450 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as acellular telephone 1480. It may also be implemented as part of asmartphone 1482, personal digital assistant, or other similar mobiledevice.

FIG. 15 is a flowchart of an example technique 1500 for changing a playthrough a 2D interface and synchronously displaying the changed play ina 3D interface. The technique 1500 can be performed by any of a varietyof computing devices, such as the computing device 1202 described abovewith regard to FIG. 12. The technique 1500 can be performed with and/orseparately from the other described techniques.

The example technique 1500 starts at step 1502 by receiving input todisplay a play from a playbook. For example, input can be received inresponse to a user selecting a play from the list of plays provided inthe pane 122, as described above with regard to FIG. 2. The play anddata associated with the play (e.g., player data, route data) can beretrieved (step 1504). For example, the computing device 1202 canretrieve the play and other associated data from the data repository1214 described above with regard to FIG. 12. The play can be displayedand/or animated in a 2D interface and a 3D interface using the retrieveddata (step 1506). For example, a play is displayed and animated in the2D interface 102 and the 3D interface 104, as described above withregard to FIGS. 1-10.

Input can be received through the 2D interface that causes at least aportion of the play to be changed (e.g., change formation, adjustroutes, adjust player attributes) (step 1508). For example, FIG. 8depicts a screenshot 800 in which a user moves the player 106 and theplayer's route 108 further into the backfield in the 2D interface 102.In response to receiving the input, the display in the 3D interface canbe automatically updated to reflect the change to the play (step 1510).For example, the screenshot 800 in FIG. 8 depicts the 3D interface 104being updated to reflect the change in the position of the player 110based on the change made to the play in the 2D interface 102.

FIG. 16 is a flowchart of an example technique 1600 for changing a playthrough a 3D interface and synchronously displaying the changed play ina 2D interface. The technique 1600 can be performed by any of a varietyof computing devices, such as the computing device 1202 described abovewith regard to FIG. 12. The technique 1600 can be performed with and/orseparately from the other described techniques.

The example technique 1600 starts at step 1602 by receiving input todisplay a play from a playbook. For example, input can be received inresponse to a user selecting a play from the list of plays provided inthe pane 122, as described above with regard to FIG. 2. The play anddata associated with the play (e.g., player data, route data) can beretrieved (step 1604). For example, the computing device 1202 canretrieve the play and other associated data from the data repository1214 described above with regard to FIG. 12. The play can be displayedand/or animated in a 2D interface and a 3D interface using the retrieveddata (step 1606). For example, a play is displayed and animated in the2D interface 102 and the 3D interface 104, as described above withregard to FIGS. 1-10.

Input can be received through the 3D interface that causes at least aportion of the play to be changed (e.g., drag and drop player todifferent location in 3D space, adjust route and/or timing of route in3D, change formation, adjust player attributes) (step 1608). Forexample, a user can adjust a route alone which the player 110 is movingin the 3D interface 104 of the screenshot 800 in FIG. 8. In response toreceiving the input, the display in the 2D interface can beautomatically updated to reflect the change to the play (step 1610). Forexample, the 2D interface 102 can be updated to depict the player 106and the route 108 moved further into the backfield for the play based onthe changes in the 3D interface 104, as depicted in the screenshot 800in FIG. 8.

FIG. 17 is a flowchart of an example technique 1700 for adjusting theanimation of plays to account for route attributes, player attributes,and/or variability. The technique 1700 can be performed by any of avariety of computing devices, such as the computing device 1202described above with regard to FIG. 12. The technique 1700 can beperformed with and/or separately from the other described techniques.

The example technique 1700 starts at step 1702 by receiving input todisplay a play from a playbook. For example, input can be received inresponse to a user selecting a play from the list of plays provided inthe pane 122, as described above with regard to FIG. 2. The play,associated routes, and route attributes can be retrieved (step 1704).For example, the computing device 1202 can retrieve the play, associatedroutes, and route attributes from the data repository 1214 describedabove with regard to FIG. 12. Attributes for the players in the play canalso be retrieved (step 1706). For example, the computing device 1202can retrieve the player attributes from the data repository 1214described above with regard to FIG. 12. The play can be displayed and/oranimated in a 2D interface and a 3D interface using the retrieved data(step 1708). For example, a play is displayed and animated in the 2Dinterface 102 and the 3D interface 104, as described above with regardto FIGS. 1-10.

Movement in the 2D interface and the 3D interface of at least some ofthe players can be adjusted based on the retrieved route attributesand/or the player attributes (step 1710). For example, player attributescan include a variety of details regarding a player and how that playermay physically move, such as a player's size, speed, ability level,and/or appearance. Route attributes can include a variety of detailsregarding how a route is to be run, such as timing of the route and orspeeds at which various portions of the route should be run. Themovement of players along routes of a play can be adjusted in a 2D and a3D interface, such as the 2D interface 102 and the 3D interface 104described above with regard to FIGS. 1-10, based on the particularroutes that are being run and the players that are running them.

In some implementations, variability can be applied to at least aportion of the players in the play (step 1712). Such variability can beused to account for variances in performance and can allow for a user toview various scenarios that may arise when a given play is run. Forexample, a wide receiver's route can be varied so that the receivermakes a cut earlier than expected along the route. Such a variabilitycan be used to adjust the movement in the 2D and 3D interfaces for theat least a portion of the players in the play (step 1714). The movementof players along routes of a play can be adjusted in a 2D and a 3Dinterface, such as the 2D interface 102 and the 3D interface 104described above with regard to FIGS. 1-10, based on the appliedvariability so as to allow users to view how possible scenarios for aplay in both 2D and 3D space.

FIG. 18 is a flowchart of an example technique 1800 for generatingvideos from a playbook for particular players and/or positions. Thetechnique 1800 can be performed by any of a variety of computingdevices, such as the computing device 1202 described above with regardto FIG. 12. The technique 1800 can be performed with and/or separatelyfrom the other described techniques.

The example technique 1800 starts at step 1802 by receiving input togenerate player and/or position videos from a playbook. For example,input can be received in association with the playbook presented in thepane 122, as depicted in FIG. 2, that requests one or moreposition/player videos to be generated. The plays and associated datafor the playbook can be retrieved (step 1804). For example, thecomputing device 1202 can retrieve the plays, associated routes, routeattributes, and player attributes for the plays in the playbook from thedata repository 1214 described above with regard to FIG. 12. Informationdescribing the playbook and one or more of the plays can be displayed ina 2D interface and a 3D interface (step 1806). For example, a first playfrom the playbook can be displayed in the 2D interface 102 and the 3Dinterface 104, as described above with regard to FIGS. 1-10.

A user selection of one of more of the players and/or positions can bereceived (step 1808). For example, the user can select the player 110from the 3D interface 104 and/or the player 106 from the 2D interface102, as depicted above with regard to FIG. 4. For each of the selectedplayers/positions, a video can be generated that includes movement ofplayers along routes in the 2D interface and the 3D interface for theplays from the playbook (step 1810). For example, if the player 110 isselected, a video can be generated that includes each of the plays froma playbook (or a portion of the playbook) as run from the perspective ofthe player 110 in the 3D interface 104. Such a video can also includethe plays animated in the 2D interface 102, as described above withregard to FIGS. 1-10. Such a video may be generated in any of a varietyof appropriate video formats, such as a .mov format and/or a .mpeg2format. Such a video may include chapters/segments that each correspondto a separate play from a playbook. Each chapter/segment can include theplay run multiple times at varied speeds so that a player watching thevideo can have ample time to study the play. Such a video may includeone or more separate video files. The generated videos can be output(step 1812). For example, the computing device 1202 can display thevideos on the display 1212, provide them to the computer server system1228 and/or 1230 over the network 1226, and/or save them locally to astorage device used by the computing device 1202.

Various implementations of the systems and techniques described here canbe realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

These computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium”“computer-readable medium” refers to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor)for displaying information to the user and a keyboard and a pointingdevice (e.g., a mouse or a trackball) by which the user can provideinput to the computer. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to theuser can be any form of sensory feedback (e.g., visual feedback,auditory feedback, or tactile feedback); and input from the user can bereceived in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in acomputing system that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (“LAN”), a wide area network (“WAN”), peer-to-peernetworks (having ad-hoc or static members), grid computinginfrastructures, and the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

Although a few implementations have been described in detail above,other modifications are possible. Moreover, other mechanisms forproviding a 3D playbook may be used. In addition, the logic flowsdepicted in the figures do not require the particular order shown, orsequential order, to achieve desirable results. Other steps may beprovided, or steps may be eliminated, from the described flows, andother components may be added to, or removed from, the describedsystems. Accordingly, other implementations are within the scope of thefollowing claims.

What is claimed is:
 1. A computer-implemented method comprising:receiving, at a computing device, user input to display a sports playthat involves a plurality of players; displaying, by the computingdevice, the play in both a 2D interface and a 3D interface using dataassociated with the play and the plurality of players; in response to anindication for the 3D interface to use a camera view that follows aparticular player from among the plurality of players, adjusting thecamera view of the 3D interface based on a location of the particularplayer in the play; and in response to an indication to run the play,displaying the plurality of players moving synchronously in the 2Dinterface and in the 3D interface in a manner determined before the playis run and according to routes associated with the players, wherein the3D interface displays the synchronous motion of the players from thecamera view based on the location of the particular player and a routeassociated with the particular player.
 2. The method of claim 1, furthercomprising: receiving input through the 3D interface that causes atleast a portion of the play to be changed; and automatically updating adisplay of the play in the 2D interface to correspond to the play aschanged in the 3D interface.
 3. The method of claim 1, furthercomprising: receiving input through the 2D interface that causes atleast a portion of the play to be changed; and automatically updating adisplay of the play in the 3D interface to correspond to the play aschanged in the 2D interface.
 4. The method of claim 1, furthercomprising: retrieving one or more route attributes for the route thatis associated with the particular player; and adjusting movement of theparticular player in the 2D interface and the 3D interface along theroute based on the one or more retrieved route attributes.
 5. The methodof claim 4, wherein the one or more route attributes are selected fromthe group consisting of: timing information for the route that indicatesone or more times at which one or more segments of the route are to berun, and speed information for the route that indicates one or morespeeds at which the one or more segments of the route are to be run. 6.The method of claim 1, further comprising: retrieving one or more playerattributes that are associated with the particular player; and adjustingmovement or appearance of the particular player in the 2D interface andthe 3D interface along the route based on the one or more retrievedplayer attributes.
 7. The method of claim 6, wherein the one or moreplayer attributes are selected from the group consisting of: sizeinformation that identifies one or more physical measurements for theparticular player, speed information that identifies a speed at whichthe particular player moves, ability level information that indicates anability or skill level of the particular player, and appearanceinformation that identifies one or more physical characteristics of theparticular player.
 8. The method of claim 1, wherein the camera viewcomprises a point of view for the particular player that causes the 3Dinterface to display the play from the particular player's perspective.9. The method of claim 1, wherein the camera view comprises a view aboveand behind the particular player that causes the 3D interface to displayat least a portion of the particular player.
 10. A computer programproduct tangibly embodies in a non-transitory computer readable mediumincluding instructions that, when executed, cause a computing devicewith a processor to perform operations comprising: receiving, at acomputing device, user input to display a sports play that involves aplurality of players; displaying, by the computing device, the play inboth a 2D interface and a 3D interface using data associated with theplay and the plurality of players; in response to an indication for the3D interface to use a camera view that follows a particular player fromamong the plurality of players, adjusting the camera view of the 3Dinterface based on a location of the particular player in the play; andin response to an indication to run the play, displaying the pluralityof players moving synchronously in the 2D interface and in the 3Dinterface in a manner determined before the play is run and according toroutes associated with the players, wherein the 3D interface displaysthe synchronous motion of the players from the camera view based on thelocation of the particular player and a route associated with theparticular player.
 11. The computer program product of claim 10, whereinthe operations further comprise: receiving input through the 3Dinterface that causes at least a portion of the play to be changed; andautomatically updating a display of the play in the 2D interface tocorrespond to the play as changed in the 3D interface.
 12. The computerprogram product of claim 10, wherein the operations further comprise:receiving input through the 2D interface that causes at least a portionof the play to be changed; and automatically updating a display of theplay in the 3D interface to correspond to the play as changed in the 2Dinterface.
 13. The computer program product of claim 10, wherein theoperations further comprise retrieving one or more route attributes forthe route that is associated with the particular player; and adjustingmovement of the particular player in the 2D interface and the 3Dinterface along the route based on the one or more retrieved routeattributes.
 14. The computer program product of claim 10, wherein theoperations further comprise retrieving one or more player attributesthat are associated with the particular player; and adjusting movementor appearance of the particular player in the 2D interface and the 3Dinterface along the route based on the one or more retrieved playerattributes.
 15. The computer program product of claim 10, wherein thecamera view comprises a point of view for the particular player thatcauses the 3D interface to display the play from the particular player'sperspective.
 16. The computer program product of claim 10, wherein thecamera view comprises a view above and behind the particular player thatcauses the 3D interface to display at least a portion of the particularplayer.
 17. A computer system comprising: a computing device thatincludes at least one processor; an input device of the computing deviceto receive user input to display a sports play that involves a pluralityof players; a display of the computing device to display the play inboth a 2D interface and a 3D interface using data associated with theplay and the plurality of players; and a 3D playbook application of thecomputing device to: i) adjust a camera view of the 3D interface basedon a location of a particular player in the play in response receivingan indication for the 3D interface to follow the particular player fromamong the plurality of players, and ii) cause the display to present theplurality of players moving synchronously in the 2D interface and in the3D interface in a manner determined before the play is run and accordingto routes associated with the players, wherein the 3D interface displaysthe synchronous motion of the players from the camera view based on thelocation of the particular player and a route associated with theparticular player.
 18. The computer system of claim 17, wherein theinput device is further configured to receive input associated with the3D interface that causes at least a portion of the play to be changed;and wherein the 3D playbook application is further configured toautomatically update a display of the play in the 2D interface tocorrespond to the play as changed in the 3D interface.
 19. The computersystem of claim 17, further comprising a data repository to store one ormore player attributes that are associated with the particular player;wherein the 3D playbook application is further configured to adjustmovement or appearance of the particular player in the 2D interface andthe 3D interface along the route based on the one or more playerattributes.
 20. The computer system of claim 17, further comprising adata repository to store one or more route attributes for the route thatis associated with the particular player; wherein the 3D playbookapplication is further configured to adjust movement of the particularplayer in the 2D interface and the 3D interface along the route based onthe one or more retrieved route attributes.